… silent partial results

Previously, Get-StmClusteredScheduledTaskInfo silently emitted partial results
(TaskName-only) when a named task could not be resolved on a cluster, and
Get-StmClusteredScheduledTask fired a misleading "configure your cluster"
warning for what was actually a single-named-task miss.

Three changes across two files:

- Get-StmClusteredScheduledTask.ps1: when -TaskName is given and the cluster
  returns zero, write a structured ClusteredScheduledTaskNotFound error instead
  of a cluster-wide warning. Bulk path (no -TaskName) keeps the warning.
- Get-StmClusteredScheduledTask.ps1: detect stage-B misses (cluster registry
  has the task but the owner node didn't return it) and write a structured
  ClusteredScheduledTaskOwnerLookupFailed error per missing task. Suppresses
  the raw cmdletization error leak from the per-name Get-ScheduledTask call.
- Get-StmClusteredScheduledTaskInfo.ps1: when -TaskName is given and the inner
  lookup is empty, write a structured ClusteredScheduledTaskNotResolvable
  error. Bulk path keeps the warning.

Five new Pester tests across the two .Tests.ps1 files cover both error paths
and verify the preserved bulk-path warnings. Validated red-then-green:
new tests fail against pristine module, pass with patches. Also validated
end-to-end against a real failover cluster in the integration lab.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… contract

Drop the stale "Should warn" unit test — its scenario is now covered by the
PR's new structured-error tests (`ClusteredScheduledTaskOwnerLookupFailed`),
and its old warning-based assertion no longer matches the post-#42 behavior.

Switch four integration-test cleanup probes from `-EA SilentlyContinue` to
`-EA Ignore`. `Ignore` does not pollute `$Error`; `SilentlyContinue` does.
The polluted `$Error` was leaking across the PSRemoting boundary into
psake's `$ErrorActionPreference = 'Stop'` scope and failing the build at
`build.psake.ps1:266` after all 19 integration tests had passed.

Probe-then-act pattern is preserved (Unregister-* is still terminating on
missing tasks); collapsing to one-line idempotent cleanup is tracked in #44.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ify step

Disable-StmClusteredScheduledTask's verify-after-unregister called
Get-StmClusteredScheduledTask with -ErrorAction Stop, expecting a silent
null when the task was successfully unregistered. After this PR introduced
the new ClusteredScheduledTaskNotFound error on the named-task path, that
Get call now throws terminating on the SUCCESS case (task absent), which
the surrounding catch block wraps as UnregisterFailed and re-throws.

In the integration test, the "Should disable" Pester test still reported
as passed (AutomatedLab's Invoke-LabCommand appears to swallow terminating
errors from the remote lab session), but the error accumulated in the
session's error stream and surfaced ~2s after Pester finished, at the
outer Invoke-Command boundary in build.psake.ps1:266 where psake's
$ErrorActionPreference = 'Stop' promoted it to a build failure.

Empirically verified locally: Get-StmClusteredScheduledTask with the exact
splat Disable used (-EA Stop, -WA SilentlyContinue) throws terminating
with FQEI ClusteredScheduledTaskNotFound when the task is missing.

Switch to -ErrorAction Ignore on the verify-Get: a missing task here is
the SUCCESS condition. The existing `$taskExists = $null -ne $task` check
correctly drives the success/failure branch without depending on the
producer's error contract.

Audit of other internal Get-StmClusteredScheduledTask callers:
- Import-StmClusteredScheduledTask: -EA Stop, but wraps in try/catch that
  treats throw as 'doesn't exist'. Robust to both old and new behavior.
- Enable/Export/Set/Start/Stop/Wait/Get-Info: all expect the task to
  exist; surfacing 'not found' as an error is the correct behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>